Hello, Thanks for your response. Have you tested this? As I'm fairly sure that's what Numbers is doing. NSMetadataQueryUpdateRemovedItemsKey and NSMetadataQueryDidUpdateNotification which are iCloud Document API, have the following two limitations. Therefore, I believe Numbers uses other methods as well. On iOS, NSMetadataQuery cannot handle files stored in local storage. File changes can only be detected while the app is running. Also, and I should have mentioned this in my previous reply, make sure you're using file coordination for all of this. We found that it is possible to detect deletion of files in local storage while the app is running by using the NSFilePresenter API. However, these APIs unable to detect whether a file was deleted while the app was not running. If there is a better way than checking whether the URL contains “.Trash” to determine whether a file was deleted while the app was not running—like the method used by Numbers.app—we would like to adopt it in our app as well. That said, as you mentioned, considering real user behavior, detecting whether the URL contains “.Trash” should be sufficient. If the approach used by Numbers.app relies on Apple private APIs, we understand that it would not be available to third-party developers, and in that case, we will proceed with the “.Trash” URL check approach.

Sorry for late response. Since we have several additional question regarding Number.app, so opened a new post in the following. https://developer.apple.com/forums/thread/818723 If possible, please share it to the developer who is expertise at Number.app. Thanks for your support!

Sorry for late response. Thanks for your comment and I have 1 additional inquiry. Related to the topic which I posted, I have a question regarding the behavior of Numbers.app, which is provided by Apple. In Numbers.app, it will track the file which opened previously has moved to another location and open it. And also when that file has been deleted, it will close along with the following message. [Spreadsheet Deleted. This spreadsheet was deleted in another location] Questions: 1.How Numbers.app achiveing these behaviors? 2.Can a 3rd party like our company be able to achieve this kind of behavior?

Hello, Thanks for your detailed explanation. ...yes, please file a bug on this and post the bug number back here. Sharing your bug number regarding this topic which I previously filed. FB21561068 https://feedbackassistant.apple.com/feedback/21561068 What's the scenario it's failing at? When determining whether the URL is in “trash” location by using API with the following steps, we are seeing a failure. Precondition: Download the attached sample project (TrashedFileURL.zip) in the feedback which I shared with you in above and build the TrashedFileURL.app from the project inside the zip folder. 1.Create a file in NSDocumentDirectory by TrashedFileURL.app. a.file:///private/var/mobile/Containers/Data/Application/{Application UUID}/Documents/{File UUID}.txt 2.Save the Bookmark of the file created in 1. in TrashedFileURL.app. 3.Delete the file by Files.app. 4.Get URL of the file from the Bookmark which is saved on TrashedFileURL.app. a.URL is referring a filepath which is inside of .Trash directory. file:///private/var/mobile/Containers/Data/Application/{Application UUID}/Documents/.Trash/{File UUID}.txt 5.When running [NSFileManager URLForDirectory:NSTrashDirectory inDomain:NSUserDomainMask appropriateForURL:url create:error:] to the URL which got in 4., it will return the following Error. Error Domain=NSCocoaErrorDomain Code=3328 "The requested operation couldn’t be completed because the feature is not supported." 6.When running [NSFileManager getRelationship:ofDirectory:NSTrashDirectory inDomain:NSUserDomainMask toItemAtURL:error:] to the URL which got in 4., it will return the following Error. Error Domain=NSCocoaErrorDomain Code=256 "The file couldn’t be opened." If you need any additional information, please let me know.

Behavior has been changed by several macOS updates. Share the details in the following. All issues have not been clear yet on macOS 15.0 beta 6(24A5320a) though. macOS 14.0 - macOS 14.3 : The drawing mechanism of NSView has changed significantly, and there is a problem that even if a partial area is specified with setNeedsDisplayInRect in an app program, the full area is always passed in drawRect. macOS 14.3 - macOS 14.4: The issue with setNeedsDisplayInRect has been corrected, and the partial area is now passed in drawRect. However, another issue occurred that the number of NSView drawRect and mouseDragged events gradually decreased when continuously performing setNeedsDisplayInRect on a partial area. macOS 14.5: Even if a partial area is specified in setNeedsDisplayInRect in an app program and drawn continuously, the system will now periodically draw the entire area. This change has eased the problem of events-decreasing which are described above. macOS 15.0 beta (24A5289h) : The number of events such as drawRect and mouseDragged in NSView has been dramatically reduced, so the regular full-area drawing by the system described above is no longer useful and is worse than in macOS 14.4. macOS 15.0 beta 4 (24A5298h) : It is back to macOS 14.5 equivalent behavior. macOS 15.0 beta 6 (24A5320a) : No change. Even on the latest macOS 15.0 beta 6 (24A5320a), there is an issue that the system periodically draws the whole area even if a partial area is specified in setNeedsDisplayInRect and drawn continuously. macOS 13 did not have such an issue.